Method and system for dynamic business process management using a partial order planner

ABSTRACT

A dynamic business process management system and method is disclosed for providing using a least commitment planner to better handle the changes and uncertainties that inevitably occur in the real-world. An embodiment of the invention provides a dynamic business process management system using partial-order planning. An additional embodiment of the present invention includes an intent interpreter module that supports the implementation of intelligent decision support functionality in a corporate information management interface.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patentdisclosure, as it appears in the Patent and Trademark Office patentfiles or records, but otherwise reserves all copyright rightswhatsoever.

FIELD OF THE INVENTION

The present invention relates to the field of business processmanagement, and more particularly to an extended enterprise operationssystem using a least commitment planner to more effectively handle everchanging real-world business situations by providing a dynamic businessprocess management system.

BACKGROUND INFORMATION

Enterprise resource planning (ERP) systems are often touted as attemptsto provide a single solution for integrating business processes acrossan organization, or even across an entire supply chain, tying inventorycontrol systems, manufacturing resource planning, sales and ordermanagement, marketing, purchasing, warehouse management, financial andmanagerial account, and human resource management so that all businessprocesses are at the fingertips of corporate executives. In effect, ERPis an attempt to reduce all aspects of a business to a model that canthen be tested, simulated, modified, refined, and examined so that acorporate manager can increase the efficiency of the entire business.

The use of ERP systems has increased business efficiency, especially forlarge, complex manufacturing operations. By providing the ability tosimulate various scenarios, ERP systems assist managers to moreeffectively handle business process problems such as shortages, laborproblems, quality control problems, etc. In short, by reducing businessprocesses to a model of resources and constraints, ERP systems provide atool for viewing the current state of an operation and a test bed forconsidering modifications to business processes.

Conventional ERP systems operate by treating business process modelingand simulation as a scheduling problem. A business is modeled as a setof processes, a collection of resources and a set of constraints wherebya company must determine how best to use its limited resources toachieve the largest benefit attainable. By solving the schedulingproblem, conventional ERP systems attempt to provide a fully-orderedplan that optimally solves the problem presented to it.

Scheduling is a subproblem of the more general problem of planning. Tocharacterize this, the following definitions are broadly accepted:

Scheduling subproblem: given a set of activities a_(l) . . . a_(n), withprecedent relationships a_(j)>a_(k), and a set of resources r_(l) . . .r_(m) needed to perform the activities, what is the best allocation andordering of the activities and resources. Best is normally expressed asthe optimal value of some expression J(r_(i)) that is related to thecost of the resources used and the benefits obtained.

Planning subproblem: given one or more objectives, what is the best setof activities a_(l) . . . a_(n) and what are the precedencerelationships a_(j)>a_(k) that exist between them to accomplish thedesired objectives.

Clearly, these definitions imply that the scheduling subproblem cannotbe approached until after the planning subproblem has been solved. Inaddition, each of these subproblems, when formulated for real-worldcases other than relatively trivial textbook examples, are easily withinthe class of problems known in computing theory as NP-Complete.

Current approaches to ERP and SCM typically assume a static set ofactivities as the business model. In pursuing a resource allocation,these ERP and SCM optimization processes can change attributes ofactivities, such as start and end times and allocation of resources toactivities, but conventional ERP and SCM systems do not seek to changethe set of activities themselves. This static set of activities definesa static business model.

Unfortunately, a static ERP business model cannot be completely accurateand cannot account for all contingencies. In actuality, there are manypotential variations in the business models of companies. As goalschange, the business processes themselves may need to be fundamentallychanged. Often, the optimal schedule is not the best plan to handle theuncertainties of the real world because it is not the most robust. Inthe real world, requirements and resources are not static. The operationof a business is a dynamic process and it is desirable to provide asystem for dynamic business process management that can better handlethe inevitable changes that confront a corporate manager every day. Itis desirable to provide a system for dynamic modification of businessprocess models that permits dynamic changes in the planned set ofactivities as well as the schedule and resource allocations.

The value of planning is solely in its ability to improve the executionof a complex undertaking. The improvements may take the form of moreeffective resource allocation or more effective coordination betweenparties or more certain outcomes. The creation of plans that do notimprove execution is itself a poor use of resources.

Determining an optimal plan in the face of uncertainty is often a wasteof resources because the available resources and constraints inreal-world problems change over time, sometimes faster than a newoptimal plan can be recalculated. Before an optimal plan is completelycarried out, a change will often force reconsideration andrecalculation. Because solving the optimal scheduling subproblem istypically very computationally expensive, changes may occur in thepre-conditions before the result can even be calculated. Optimalschedulers do not have a mechanism for graded levels of commitment toactivities and their parameters. When a change occurs, the entireschedule must be re-computed. As a result, a small change in inputvalues to the optimal scheduler can produce a large change in theresulting schedule. Activities that were once possible to schedule maynow become unscheduled. Conventional ERP systems attempt to createso-called “optimal” or fully ordered plans often requiring repeatedreconsideration and recalculation.

An alternative view to optimal planning emphasizes adaptation. Moderncontrol theory is based on adaptation. For example, the driver of a cardoes not plan about steering the car to stay on the roadway. Instead,steering behavior is continuously adapted to meet the needs of thesituation. However, pure adaptation is not fully effective either—unlessthe driver has a plan in the form of an intended route to hisdestination, he may well become lost.

Partial order, least commitment planning is a method that blendsplanning and adaptation to produce robust behaviors. Activities are onlypartially planned, leaving many details to be determined by adaptationduring the actual execution. However, the extent of planning issufficient to ensure that the resulting behavior is feasible and cannominally be performed. Partial-order, least commitment planning allowsan extended business enterprise to adapt flexibly to the changes in dayto day operations while still achieving coordination and feasibility. Itis desirable to provide a dynamic business process management systemthat calculates partial-order, least commitment plans for operating abusiness enterprise.

Partial order, least commitment planners also provide for graded levelsof commitment to a set of activities. This allows the planner tomaintain multiple alternative means to achieve multiple simultaneousgoals, and increase or decrease its level of commitment to each of thealternatives as the situation unfolds. In this way, the choice ofalternative to execute can be deferred until it is clear whichalternative is superior. A partial order least commitment planner isalso able to select multiple alternatives for execution as a means forhedging against uncertainty in outcomes.

Additionally, as business processes become more complex and as modelsbecome more detailed, the optimal planning mechanisms of conventionalERP systems takes longer and longer to complete. Many algorithms forschedule optimization have execution times of Order (n-cubed) orgreater. Some optimal scheduling problems are known to be members of thevery difficult and expensive class of problems known as NP-complete. Itis therefore desirable to provide a planning mechanism that is fasterthan conventional optimal, fully-ordered planners Corporate managersdesire fast, perhaps even real-time feedback and adaptation to cope withdynamic business situations.

Several related patents have been issued by the United States Patent andTrademark Office. For example, U.S. Pat. No. 5,299,287 issued to Tsurutaet al. (the '287 patent) discloses a method of knowledge management fordividing a goal into lower level subgoals. Additionally, the '287 patentdiscloses a system for cooperative goal and plan sharing between actorsin the system. There is a need for a system that incorporates goaldecomposition and cooperative planning in a business process managementsystem. There is also a need for a system that performs partial orderplanning to better handle real-time, dynamic business process systems.

SUMMARY OF THE INVENTION

In accordance with the present invention, a system for conductingdynamic business process management for extended enterprise operationsusing partial order, least commitment planning is provided. The systemincludes a knowledge base for storing expert knowledge about one or morebusiness process domains, an inference engine coupled to the knowledgebase that includes a least commitment planner, a management system thatcollects data regarding one or more business processes and determinesone or more goals, and a graphical user interface system that displaysinformation regarding business processes. The inference engine uses thepartial order, least commitment planner to determine one or more plansfor achieving one or more determined goals.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is further described in the detailed descriptionwhich follows, by reference to a plurality of drawings by way ofnon-limiting examples of illustrated embodiments of the presentinvention, in which like reference numerals represent similar partsthroughout the several drawings, and wherein:

FIG. 1 is a block diagram illustrating a typical business processmanagement system according to an embodiment of the present invention;

FIG. 2 is a block diagram describing a software implementation of anbusiness process management system according to an embodiment of thepresent invention;

FIG. 3 illustrates an inference engine for performing least commitmentplanning according to one embodiment of the present invention;

FIG. 4 is a block diagramming describing the life cycle of a planmaintained by a planner according to one embodiment of the presentinvention;

FIG. 5 illustrates a portion of a concept graph according to oneembodiment of the present invention;

FIG. 6 illustrates a portion of a plan-goal graph (PGG) according to oneembodiment of the present invention;

FIG. 7 describes a goal instance created by an intent interpreteraccording to one embodiment of the present invention; and

FIG. 8 depicts a portion of a plan-goal graph (PGG) illustrating theoperation of a planner according to one embodiment of the presentinvention.

GLOSSARY

Concept Graph: a knowledge representation of the dependencies betweenobservable data values and higher-level computations and assertions madeabout the data. A concept graph can be implemented as a directed acyclicgraph of concept nodes that is a particular type of augmented transitionnetwork (ATN).

Expert System: a computer program that uses a knowledge base to assistin solving problems. Most expert systems use an inference engine toderive new facts and beliefs using a knowledge base.

Full-Order Planner: (also called a total-order planner) a process thatcomputes a fully-ordered list of primitive steps or actions to reach agoal, in which each step or action is fully definitized at thecompletion of the planning process.

Inference Engine: a computer program that infers new facts or beliefsfrom known facts or beliefs using a knowledge base and a set of logicaloperations.

Intent Interpreter: an expert system that uses a knowledge base todetermine the present intention of a user or a system.

Knowledge Base: a collection of knowledge (e.g., objects, concepts,relationships, facts, rules, etc.) expressed in a manner such that itcan be used by an inference engine. For example, a knowledge base mayinclude rules and facts or assertions as in traditional expert systems.

Least Commitment Planner: a process that generates a plan that avoidsmaking a choice between two or more alternative courses of action unlessit is necessary to do so. A least commitment planner avoids definitizingany particular sub-element of a plan beyond the minimum necessary todetermine likely success. Final definitization of the primitive steps isdeferred until just prior to the execution of each plan sub-element by aplan execution agent.

Primitive step. a representation of an activity that is not furtherdecomposed by a planner. Also called a primitive action.

Partial-Order Planner: a process that generates a partially ordered setof activities at the completion of the planning process.

Plan. a abstract representation of a set of activities to be performedfrom the present into the future. A plan may be decomposable into plansub-elements that define more detailed activities. The lowest level ofdecomposition of a plan is a primitive step or action.

Plan Execution Agent. a process that directly operates on theenvironment by performing activities represented by a plan.

Plan-Goal Graph (PGG): a knowledge representation for expressing causalrelationships in an operational domain as well as the intentions of auser. A PGG can be expressed as an acyclic, directed graph where plansare decomposed into subgoals or primitive actions.

Planner: a computer program that determines a sequence of operations oractions to be taken to reach one or more goals.

Non-Monotonic Truth Maintenance: a system for maintaining theconsistency of beliefs, assumptions, justifications and/or assertions ina knowledge base wherein knowledge can be retracted when aninconsistency is detected.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS

The present invention includes methods and systems for providing dynamicbusiness process management services with partial order, leastcommitment planning. Conventional enterprise resource planning (ERP)systems are known in the art such as those marketed by SAP™, JDEdwards™, Oracle™, and Peoplesoft™. The embodiment described below is asoftware implementation of the present invention that improves uponconventional ERP systems. Using the following description, one ofordinary skill in the art will be able to practice the present inventionusing conventional software development tools and techniques. Thepreferred embodiment of the present invention is developed in C++ on aSun Microsystems™ server running the Solaris™ operating system.

The various embodiments of the present invention improve on traditionalartificial techniques. One of ordinary skill in the art may find thefollowing references helpful in providing appropriate backgroundunderstanding in the design and construction of inference engines,knowledge bases, and various knowledge representations used by thepresent invention: (1) Schank, R. C. and Abelson, R., Scripts, PlansGoals and Understanding, Hillsdale, N.J.: Lawrence Erlbaum Associates(1977); (2) Schank, R. C. and Riesbeck, C. K., Inside ComputerUnderstanding. Hillsdale, N.J.: Lawrence Erlbaum Associates (1981); (3)Sacerdoti, E. D., A Structure for Plans and Behaviors, N.Y.: Elsevier(1978); (4) Rinnooy Kan, A.H.G., Machine Scheduling Problems. The Hague:Martinus Nijhoff (1976); and (5) Charniak, E, Riesbeck, C. K. andMcDermott, D., Artificial Intelligence Programming. Hillsdale, N.J.:Lawrence Erlbaum Associates (1980).

FIG. 1 is a block diagram illustrating a dynamic business processmanagement system. In this implementation, there are three basic groupsof functionality implemented as an integrated toolset for businessinformation management. The functional groups include the following: (1)Finance 101; (2) Human Resources 102; and (3) Manufacturing/Logistics103.

Finance 101 provides various components to assist corporate managers inbookkeeping. For example, the dynamic business process management systemincludes a general ledger 113 for maintaining a list of all accounts,both internal and external to the corporation. The general ledger 113provides an information store that includes all accounting details ofthe corporation as well as analysis tools.

In addition to the general ledger 113, the Finance 101 component of thedynamic business process management system includes both an accountsreceivable 110 component and an accounts payable 112 component. Accountspayable 112 tracks all bills that must be paid by the company andprovides tools for scheduling payments and analyzing the outflow ofcorporate resources. On the other hand, accounts receivable 110maintains customer accounts and other moneys owed to the corporation.Together, accounts receivable 110 and accounts payable 112 provideaccounting tools that assist corporate managers analyze and track theflow of cash through the corporation.

Next, the fixed assets 111 component of the Finance 101 resources isinformation store and toolset for managing and tracking tangible,depreciable assets such as buildings, equipment, and property. Thiscomponent allows a corporation to track depreciation and expensesassociated with these assets.

Human Resources 102 provides various components to administer andmaintain human resource information and processes. For example, acorporation must maintain information regarding their employees such ashome addresses, Social Security Numbers, dates of employment, salaryinformation, etc. The present implementation of a dynamic businessprocess management system includes a personnel management 120 componentthat maintains all necessary information about each employee includingthe employee's name, home address, supervisor, Social Security Number,tax withholding information, date of employment, etc. Closely tied tothe personnel management 120 system is a payroll 121 system. Payroll 121provides an information management solution that assists the corporationin paying its employees.

Finally, Manufacturing/Logistics 103 provides components for managingbusiness processes associated with the actual manufacturing operationsof a company. including: (1) capacity planning 130; (2) order entryprocessing 131; (3) transportation management 132; (4) projectmanagement 133; and (5) customer service 134.

The capacity planning 130 module of the present dynamic business processmanagement system implementation assists companies in planning the dailyproduction schedule for a corporation's manufacturing facilities. Forexample, capacity planning 130 may help an automobile manufacturerdetermine the efficient use of an assembly line. If there is a predictedsurplus of parts, capacity planning 130 may help adjust production tomeet the demands of the market.

The order entry processing 131 system helps a corporation monitor andprocess orders placed by customers. When an order for a customer isreceived, it is entered into the order entry processing 131 system. Byhaving this data integrated with manufacturing data, corporations arebetter able to adjust production to meet the demands of customers.Closely tied to order entry processing 131 is transportation management132. Once a customer's order is ready to be delivered, transportationmanagement helps plan, schedule, and track the delivery.

In any corporation, there are numerous projects that are ongoing at anypoint in time. The Project management 133 system helps corporatemanagers track the progress of each project, quickly detecting slippagesand analyzing how a slippage will affect other projects and otheroperations of the organization.

Finally, the customer service 134 component assists the corporation intracking and responding to customer inquiries and suggestions. Forexample, customer service 134 may assist a company in managing a helpdesk where customers can call in to ask questions, report problems, andobtain additional information about the corporation and its variousproducts and services.

Each of the components of a dynamic business process management systemdescribed above including Finance 101, Human Resources 102, andManufacturing/Logistics 103 information systems are integrated toprovide a platform for corporate managers to plan, simulate, test, andobserve the day-to-day operations of a company.

FIG. 2 shows a schematic diagram describing an implementation of adynamic business process management system. Each software componentdepends on operating system 201. In the preferred embodiment of thepresent invention, operating system 201 is the Solaris™ operating systemthat runs on Sun Microsystems™ and Intel™-based computers.

The operating system 201 provides a platform for executing softwareapplications and provides a standardized interface that abstracts fromthe details of the underlying computer's hardware. A database 202 is runon top of operating system 201 providing a mechanism for storing,search, and retrieving large amounts of data. In the preferredembodiment of the present invention, database 202 is an Oracle™database.

Using database 202 and operating system 201, inference engine 203provides the tools and framework for performing least commitmentplanning. In conventional ERP systems, inference engine 203 is anoptimal scheduler. The present invention improves on the prior art byproviding a partial-order, least commitment planner to increase theperformance and to better handle the uncertainties and challengesencountered in the real-world.

Finally, the graphical user interface 205 provides a mechanism forinteracting with users by displaying data on a computer screen and byreceiving user input from a device such as a mouse, keyboard, or touchscreen.

FIG. 3 is a schematic diagram illustrating inference engine 203according to one embodiment of the present invention. Inference engine203 includes one or more planners 302, an intent interpreter 303, aninformation manager 304, a script performer 305, a knowledge base 306,and a situation assessor 307. Each of these components is described inmore detail below. In addition, the following publications describingvarious exemplary implementations of the constituent components of aninference engine are hereby incorporated by reference: (1) Hoshstrasser,Belinda Hardman and Norman D. Geddes. Proceedings of the InternationalJoint Conferences on Artificial Intelligence 1989 Workshop on IntegratedHuman-Machine Intelligence in Aerospace Systems. OPAL: Operator IntentInferencing for Intelligent Operator Support Systems. (Aug. 21, 1989);(2) Geddes, Norman D., et al. Fostering Collaboration in System ofSystems; (3) Rouse, William B., et al. An Architecture for IntelligentInterfaces: Outline of an Approach to Supporting Operators of ComplexSystems. Human-Computer Interaction, vol. 3, pp. 87-122 (1987); (4)Geddes, Norman D. and Mark A. Hoffman. Supervising Unmanned RovingVehicles Through an Intelligent Interface; (5) Geddes, Norman D., et al.Automated Acquisition of Information Requirements for an IntelligentDisplay; (6) Miller, Christopher A., et al. Plan-Based InformationRequirements: Automated Knowledge Acquisition to Support InformationManagement in an Intelligent Pilot-Vehicle Interface. Digital AvionicsSystems Conference (Seattle, Wash., Oct. 5-9, 1992); (7) Geddes, NormanD., Large Scale Models of Cooperative and Hostile Intentions. IEEEComputer Society, International Conference and Workshop on Engineeringof Computer Based Systems (ECBS'97) (Monterey, Calif., Mar. 27-28,1997); (8) Webb, Barry W., Norman D. Geddes, and Leslie O. Neste.Information Management with a Hierarchical Display Generator; (9) Rouse,W. B., N. D. Geddes, and J. M. Hammer. Computer-aided fighter pilots.IEEE Spectrum. pp.38-41 (March 1990); (10) Geddes, N. D. and R. J. Lee.Intelligent Control for Automated Vehicles: A Decision Aiding Method forCoordination of Multiple Uninhabited Tactical Aircraft. Association forUnmanned Vehicle Systems International AUVSI'98 25th Annual Symposiumand Exhibition. (Huntsville, Ala., Jun. 8-12, 1998); (11) Geddes, N. D.,R. J. Lee, and J. L. Brown. A Portable Lightweight Associate for UrbanHelicopter Pilotage. Submitted to IEEE (Sep. 25, 1997); and (13) Geddes,N. D. “Associate Systems: A framework for human-computer cooperation.”7th International Conference of Human-Computer Interaction. (SanFrancisco, Calif., Aug. 24-29, 1997).

First, we discuss the one or more planners 302. Any conventional plannercan be used with the present invention; however, the preferredembodiment uses a real-time, partial-order, least-commitment planner.Such a planner is able to effectively manage real-time operation in achanging world. In a business system, the current state of the system isconstantly changing. For example, new orders are being placed,efficiencies change, consumer supply fluctuates, and the availability oflabor and parts changes. A dynamic business process management systemthat only plans to the level of detail necessary to ensure feasibilityfor given constraints conserves resources by preventing excessiveplanning in a dynamic environment where preferences, goals, andintentions are always changing. Additionally, by only planning as far inadvance as is necessary, a system can preserve options so assets are notcommitted until they are needed. In one embodiment of the presentinvention, the partial order, least commitment planner uses an abstractdecomposition of the business objectives. This decomposition isrepresented as a plan and goal graph (PGG), an acyclic, directed graphthat represents the hierarchy of possible goals that may be pursued toachieve an intention and the methods (or plans) that can be used tosatisfy each goal Broad, general plans are represented by plan nodes ofthe PGG that are higher in the directed acyclic graph structure, whilelower-level plan sub-elements provide increasing levels of detail in thelower levels of the PGG. A partial order planning system using a planand goal graph (PGG) is. described by N. D. Geddes and R. J. Lee in apaper entitled “Intelligent Control for Automated Vehicles: A DecisionAiding Method for Coordination of Multiple Uninhabited TacticalAircraft” published June 1998.

Traditional ERP systems use a full-order planner. A planner determines asequence of activities that can be taken to achieve as many desiredstates or goals as possible given available resources and domainconstraints. A full order planner determines the “optimal” sequence ofactivities to be taken. Because this process requires searching allcombinations of activities to determine the best combination, it isorder n-cubed or worse in the number of activities. Partial orderplanners compute less than the “optimal” sequence of.activities to betaken. For example, one type of partial order planner is a leastcommitment planner that operates by committing to as little as possible,thus reducing exponential growth of the search space resulting inincreased planning speed. Since all plans are not necessarilyconsidered, a partial order planner may not find the optimal sequence ofactivities for reaching one or more goals; however, a plan thatsatisfies domain and resource constraints will be quickly provided andthe resulting plan can be recalculated as changes occur.

In one embodiment of the present invention, the planner 302 is a partialorder planner and manages its level of commitment to the activities inthe plan by using a state transition method to set the life cycle statesof plan sub-elements. One embodiment of the plan life cycle statetransitions is shown in FIG. 6. As a plan sub-element moves through itslife cycle states from candidate towards the active state, the partialorder planner is increasing its commitment to that plan sub-element. Thepartial order planner may also reduce its commitment by changing theplan sub-element state to rejected state or revoked state and ultimatelyto a terminated state. This mechanism provides a non-monotonic, gradedlevel of commitment for each plan sub-element.

In one embodiment of the present invention, state transitions of theplan sub-elements are performed by the planner 302 in response to eventsignals received from the situation assessor 307. When the planner 302moves a plan sub-element to a new life cycle state, the planner 302requests the activation of specific monitors within situation assessor307. In one embodiment of the present invention, the monitors representthe conditions under which a plan sub-element should be transitioned toa different one of its plurality of life cycle states. The situationassessor 307 periodically evaluates the specific monitors that have beenactivated, and provides an event signal to the planner 302 for eachspecific monitor whose conditions are satisfied.

In another embodiment of the present invention, a plurality of dynamicbusiness process management systems after the present invention, andeach containing an inference engine with a planner 302, can send andreceive plan instances and life cycle changes for plan instances to eachother. In this manner, sharing of planning and graded commitment betweenthe separate dynamic business process management systems is performed,allowing all participating systems to take advantage of informationabout the plans made by another such system. The communications may takeplace over a plurality of communications means, including directconnection, telephony, wireless medium, or network, such as Internet orlocal area networks.

One embodiment of the present invention includes intent interpreter 303.In this embodiment, the dynamic business process management systemmonitors a user's actions to determine what the user is trying toaccomplish. The intent interpreter does this using a task-analyticdecomposition of the purposes of operators within the business processdomain. In the preferred embodiment, this decomposition is representedas a plan and goal graph (PGG). Additionally, intent interpreter 303uses knowledge represented as scripts. These scripts are sequences ofpartially specified primitive actions whose execution may be dependenton the state of the execution context. Other embodiments may use scriptsthat may include non-primitive actions (e.g., recursive script calls oradditional script calls). Scripts represent standard procedures orbusiness processes that are routinely used to perform specific businessprocesses described by plan sub-elements. Such standard businessprocedures may include standard responses to both normal and abnormalevents and operating conditions within an enterprise. The intentinterpreter 303 uses reasoning on the PGG to represent problem solvingbehaviors that are necessary when existing business processes defined byscripts are not appropriate for the situation. Using assertions made bythe other components of the system together with domain knowledge storedin knowledge base 306, the intent interpreter determines the most likelyintent of a user. This determined intent is then used to update theinformation being displayed to the user and to generate one or moreplans to satisfy the interpreted goals of the operator.

One embodiment of the present invention uses an intent interpretersimilar to that described by B. H. Hoshstrasser and N. D. Geddes in apaper entitled “OPAL: Operater Intent Inferencing for IntelligentOperator Support Systems” published July 1989. The intent interpreterincludes a model of user intent expressed as both scripts and plan-goalgraphs. The system tries to understand operator actions in terms of itscurrent model of user intent. An action is said to be “explained” if itis consistent with what was expected by the intent model.

The intent interpreter first tries to interpret the intent of a useraction using script-based reasoning. This is equivalent to evaluatingthe user's behavior in the context of existing active standard businessprocedures of the organization. Each active script in the current intentmodel is examined to determine if the action is an expected step in theexecution of the script. If the action matches an event in an opensegment of a script, the event is marked as completed and the useraction is explained. All active scripts are searched, even if a match isfound early on, since a particular action may occur in more than oneactive script. When the script-based reasoner runs, it evaluates thetermination conditions of each script to determine if any of the scriptsshould be removed from the current model of intent.

If the action is not predicted by the active scripts, then the systemtries plan-based reasoning to explain the action in terms of a plan tosatisfy one of the current goals of the user. In order to do this, thesystem uses a knowledge base that incorporates domain knowledge andknowledge of the possible plans and goals of the user. The knowledgebase is a relationship-based representation of the plan and goal graphfor the given domain. The PGG represents goal-driven problem solvingbehaviors of the user. The relationships also define how scripts andoperator actions are related to the low level plans. Constraints areplaced on the relationships to provide a way to account for the contextin which the action occurred.

To explain an user action through plan-based reasoning, the systembackward chains through its knowledge base to determine if the actionwas predicted by any of the current plans and goals of the user and hisorganization. This may require inferring intermediate plans and goals inorder to connect the action to a higher level plan or goal that isalready active. These new plans and goals will be invoked andincorporated into the current model of the user's intent. The intentinterpreter 303 uses non-monotonic reasoning to update the model of theuser's current intentions. As mentioned earlier, a side effect ofinferring a new plan or goal may require revoking other plans and goalsthat are found to be inconsistent with the newly added plans and goals.Scripts may be activated or revoked by the inferencing of new plans aswell. If the system is unable to explain the user's action either byscripts or plans, it is potentially an operational error by the user.

Intent interpreter 303 is a valuable, but not an essential component ofthe present invention. However, the intent interpreter 303 provides amechanism for building an intelligent decision support system to assistcorporate managers in viewing, analyzing, modifying, simulating, andtesting the business processes and the data stored in a business processmanagement system.

Script performer 305 can be used to execute multiple parallel situatedscripts that are stored in knowledge base 306. As discussed above, thesescripts are sequences of primitive actions whose execution is contextsensitive. This component is a valuable tool in increasing theefficiency of the system to support real-time performance. The scriptscan be thought of as a knowledge representation optimized for execution;just as executables can be viewed as optimized representations of sourcecode.

The information manager 304 component of this embodiment of the presentinvention provides automatic information management features for theuser interface. The information manager 304 uses knowledge stored inknowledge base 306 including the present intent of a user as determinedby intent interpreter 303 to decide what information should be displayedto the user. Information needed by a user changes as the user's tasksand intentions change. This embodiment of the present invention uses amodel to determine the information needed based on the current knowledgebase.

One embodiment of the present invention uses an information manager 304similar to that described in an article by B. W. Webb, N. D. Geddes, andL. O. Neste entitled “Information Management with a Hierarchical DisplayGenerator.” This article describes an implementation of a system thatselects and tailors the format of displayed information to the tasksbeing performed by a user.

Finally, knowledge base 306 stores all knowledge used in the system toconduct reasoning including plans, scripts, assertions, relationships,frames, etc. The knowledge base 306 includes knowledge patterns andknowledge instances. Situation assessor 307 maintains the consistency ofthe knowledge instances in the knowledge base 306 by identifying andresolving any inconsistent or outdated beliefs. In one embodiment of thepresent invention, the situation assessor uses a concept graph to updatevalues and beliefs. A concept graph is a knowledge representation of thedependencies between observable data values and higher-levelcomputations and assertions made about the data.

In one embodiment of the present invention, the concept graph includesone or more means for calculating the degree of belief that thesituation assessor 307 has in the values of each concept. One such meansfor calculating belief is Bayes Formula. When the situation assessor 307receives new data, concepts that depend on that data are updated andtheir belief values are also updated. As a result of the updated beliefvalues, the situation assessor 307 may reduce its belief in a concept,providing for non-monotonic truth maintenance for the situation assessor307.

In another embodiment of the present invention, a plurality of dynamicbusiness process management systems after the present invention, andeach containing an inference engine with a situation assessor 307, cansend and receive concept instances to each other. In this manner,sharing of situations between the separate dynamic business processmanagement systems is performed, allowing all participating systems totake advantage of results and conclusions made by another such system.The communications may take place over a plurality of communicationsmeans, including direct connection, telephony, wireless medium, ornetwork, such as Internet or local area networks.

In one embodiment of the present invention, the plans and situationsshared by a set of distributed dynamic business process managementsystems that contain inference engines after the present invention areused by the inference engines to detect conflicts in planning betweenthe collaborating companies. When a new or updated plan is received froma collaborating party by a second collaborating party, the supply chainmanagement inference engine of the second party evaluates the planprovided by the first party for conflicts with any existing plans of thesecond party. The knowledge base 306 contains specific knowledgedefining how plans and goals can be in conflict. In one embodiment, theplan and goal conflict detection uses the approach described in Geddes,N. D., A model for intent interpretation for multiple agents withconflicts (1994). When conflicts are detected with shared plans, theconflicting parties are both notified about the detailed nature of theconflict using the information manager 304.

The following is a simplified illustrative embodiment showing theinteractions between the various components of the inference engine.Consider an intelligent decision support system to assist a team ofhumans in dynamic business process management across several operatingdepartments in a company.

The starting point for the planning cycle is the posting of a high-levelgoal instance from a plan-goal graph (PGG). The posting of a goaltriggers a planning cycle that involves decomposing and specializinghigh-level goals into low-level actions that can be executed to achievethat goal. Each goal in the PGG has one or more child plans, some ofwhich can be executed directly and some that must be recursivelydecomposed into sub-goals and sub-plans and specialized until theprimitive steps are reached. Because the planner is a least commitmentplanner, commitment to a specialization created during decomposition islimited to only those aspects of the plan for which commitment cannot bedeferred. If the system has been configured to interact closely with ahuman, candidate plans that are successfully decomposed and specializedmay be proposed to the operator.

In addition to creating the decomposition of a plan into itssub-elements, the planner manages the specific life cycle states of eachsub-element of a plan. The life cycle states, depicted in FIG. 4,provide the mechanism for managing the commitment of the system to theeach of the plan sub-elements. Each of the life cycle states of a plansub-element has specific monitoring knowledge associated with it,serving to focus the processing of the situation assessor and providingfor an event-based control of the planner.

Throughout the life cycle of a PGG plan or goal, the partial orderplanner maintains the parameters of the plan or goal and monitors forits success or failure. As a result, the planner can dynamically adjustplan parameters that mediate its execution and dynamically reselect andspecialize children of a node as required.

The operation of the system begins in the situation assessor 307. In thesimplest embodiments, this component monitors and reads inputs to thesystem. The situation assessor 307 uses the inputs it receives to adddata to the knowledge base regarding the current state of the system.For example, in the present embodiment, the system monitors a user's keypresses and mouse clicks to add facts or observations to the knowledgebase 306. It may also collect data from remote data systems andfinancial systems to update the situation of importance to businessmanagement.

FIG. 5 shows a portion of a concept graph according to one embodiment ofthe present invention. The situation assessor 307 stores knowledge aboutthe situations of possible interest in the knowledge base 306 in theform of a concept graph such as the one shown in FIG. 5. The conceptgraph specifies the relationships between lower level data and higherlevel concepts. The situation assessor 307 creates concept instanceswhich represent specific data and conclusions that it determines basedon its data inputs. The concepts may represent highly aggregated andabstract conclusions about the situation of the business. Each conceptis capable of having monitors defined for it that can be activated bythe planner 302 as the life cycle states of plans and goals change overtime. For example, in FIG. 5, the concept graph shows the relationshipbetween the concept of Profit Forecast and the concepts of Cost Forecastand Price Forecast.

A monitor is a data input that can be defined by the system. Instead ofmonitoring all possible inputs at one time, embodiments of the presentinvention provide a mechanism for identifying what data is actuallyneeded. A monitor corresponding to the needed data is then activated sothat the needed data can be collected and used in the decision supportprocess.

In this embodiment, the situation assessor 307 can also send and receivecopies of concept patterns and instances by communicating with otherbusiness management systems also containing a situation assessor 307 anda knowledge base 306. The communication may be achieved by a pluralityof methods including local networks, direct connection and wide areanetworks such as the Internet.

Whenever a new fact is added to the knowledge base 306, the situationassessor 307 processes any monitors related to the new fact. If amonitor is found to be satisfied, an event is generated to the planner302 that causes the planner to update its planning.

Whenever a new fact is added to the knowledge base 306 that representsthe execution of a primitive action by the user, the intent interpreter303 processes the new assertion to update a model of the current intentof the user. The intent interpreter uses a PGG model of user intentionssuch as the portion of the one shown in FIG. 6.

FIG. 6 shows a PGG model of user intentions. For example, the top-levelplan is Company A Operations. This plan can be decomposed into threesubgoals: (1) Have Technology, (2) Have Facilities, and (3) HaveRevenue. These goals can, in turn, be decomposed into further plans andso on. A plan may also have a script for completing a plan associatedwith it or a goal may be fully decomposed into one or more primitiveactions.

The intent interpreter 303 searches through the system's PGG models ofuser intention to determine the possible and likely intentions of thecurrent user. The intent interpreter 303 then instantiates one or moregoals based on the current perceived intentions of the user.

In FIG. 7, a user at Company A performs a primitive step or action atthe user interface by placing a order request (1) with a specificcompany to purchase a quantity of finished product. The intentinterpreter 303 searches for an explanation of this action, and finds inthe knowledge base that this action is consistent with buying a productfrom the supplier. The intent interpreter 303 tentatively hypothesizesthat the user plans to buy the product as the plan (2) for satisfyingthe goal to have the product (3). The intent interpreter 303 thensearches for a higher level plan within the knowledge base 306 thatexplains the goal, and finds that there is an active plan for sellingthe finished product (4) to create revenue for Company A. Hence, theintent interpreter 303 instantiates the plan (2) and the goal (3) withinthe knowledge base 306. The posting of the new goal (3) starts theplanner 302 to consider if there are more effective alternative plansfor the goal, such as making the product at Company A.

The intent interpreter 303 uses non-monotonic reasoning in its searchthrough the PGG knowledge in the knowledge base 306. If it is unable tofind a complete path in the PGG from a hypothesized node to one known tobe active, it can back up, retract its earlier assumptions and exploreother paths.

In this embodiment, the intent interpreter 303 also sends and receivescopies of plan and goal patterns and instances by communicating withother business management systems that contain an intent interpreter 303and a knowledge base 306. The communication may be achieved by aplurality of methods, including local network, direct connection, andwide area networking such as the Internet.

Whenever a goal changes, or whenever a monitor event is received fromthe situation assessor 307, the planner 302 determines if any furtherplanning needs to take place. For example, if the intent interpreter 303instantiates a new goal, then the planner 302 needs to create a plan forachieving that goal. In the preferred embodiment, the planner 302 is aleast commitment planner that performs a search of the PGGs stored inknowledge base 306 to determine subgoals and actions that need to betaken.

When goal instances and plan instances change life cycle state, theplanner 302 uses knowledge in the knowledge base 306 to determine if anyof the newly changed or updated goal or plan instances are in conflictwith any other goal or plan instances. If a conflict is detected, theplanner 302 sends a notification to the user interface.

In FIG. 8, a user at Company A enters data defining the plan to sellproduct A (1) as a revenue source for Company A. The planner 302 usesknowledge in the knowledge base 306 to determine that product A must beobtained, and considers the make product plan (2). This plan has twosubgoals, the first of which is to have the parts available to make theproduct, and the second subgoal is to assemble the product. The planner302 uses knowledge in the knowledge base 306 to determine that theproduct assembly should not be planned until after the parts vendors areselected, so reasoning about the assembly process is deferred untillater. Once vendors are chosen, a monitor is satisfied and the planner302 can resume the solution of the assembly goal. The planner 302determines that making one of the parts (3) will be more effective thanpurchasing it and proposes this solution, leading to action (4).

One optimization that is made in the present embodiment is the use ofscript performer 305. In a particular domain, many plans are commonlyencountered and constitute a body of accepted methods known topractitioners within the domain. These plans can be implemented asscripts that represent partially specified procedures that can beexecuted without the need for extensive planning. The script performer305 is a component of the present embodiment that facilitates theexecution of scripts. These scripts are represented in the system's PGGsthat are a part of the knowledge base 306. The script performer 305 canperform many and possibly all of the primitive actions that could beperformed by a human user, but the script performer 305 is limited by aset of permissions provided by the human operator.

As an example, consider the goal of having a part, and its child plan ofbuying the part. Because the process of buying a part from a vendor is awell-defined and frequently recurring sequence of primitive actions, itcan be represented as a script. The representation of the goal, itschild plan, the script, and the relationship between the plan and thescript are all a part of the knowledge base 306.

When a specific instance of the goal of having a part, such as a stampedmetal bracket, is encountered, the planner 302 can create the instanceof the plan buy the part from a supplier. If the script performer 305has been given permission, it can execute the script and automaticallysend the order to the necessary involved parties, including the shippingagent.

The components described above provide a mechanism for assessing thecurrent situation or state of system, planning one or more responses andexecuting the course of action. The information manager 304 is used todisplay information to a user or to update the user's display based onthe current intentions or plans that have been identified by the planner302 and the intent interpreter 303 using the knowledge base 306, thescript performer 305, and the situation assessor 307.

For example, the knowledge base 306 contains a representation of theinformation that a human user would need to access if he was involved ina plan to buy a part. One type of information relevant to a plan of thiskind might be the commodity prices of the materials used in the part.When an instance of such a plan is created, such as buying an aluminumbracket from Company B, the information manager 304 uses the attributesof the plan and the knowledge base 306 to determine that the price ofspecific aluminum alloys is of interest to the human. The informationmanager 304 then commands the display presentations to show pricing datafor the correct time period.

Illustrative embodiments of the present invention have now beendescribed. It will be appreciated that these examples are merelyillustrative of the present invention. Many variations and modificationswill be apparent to those of ordinary skill in the art.

1-27. (Canceled)
 28. A business process management system comprising: atleast one knowledge base operative to store and retrieve knowledgerelated to at least one business process domain, wherein the knowledgecomprises at least one possible plan in the business process domain; auser interface operative to receive at least one goal within thebusiness process domain at least one inference engine, each inferenceengine: in communication with the knowledge base and the user interface,and comprising: a partial order planner, the partial order planneroperative to at least one plan instance from among the possible plans toachieve a goal.
 29. The business process management system of claim 28wherein the partial order planner is a least commitment partial orderplanner.
 30. The business process management system of claim 29 whereinthe least commitment partial order planner manages the level ofcommitment to the plan instance by using a state transition method toset a life cycle state of at least one element of the plan instance. 31.The business process management system of claim 28 wherein: theinference engine further comprises at least one situation assessoroperative to: activate at least one monitor in response to a requestfrom the partial order planner, and generate an event signal for eachmonitor upon satisfaction of a condition; and the partial order planneris further operative to: request activation of a monitor associated withat least one element of a plan instance upon the establishment andupdating of the life cycle state of at least one element of the planinstance; and perform a state transition of the corresponding planinstance upon receipt of an event signal.
 32. The business processmanagement system of claim 31 wherein: the knowledge further comprisesscripts and plan-goal graphs; and the inference engine further comprisesat least one intent interpreter operative to determine an intent of theuser, wherein determining the intent of a user comprises attempting oneof: explaining event signals using scripts, and explaining event signalsusing plan-goal graphs.
 33. The business process management system ofclaim 32 wherein: the inference engine uses determined intent to chooseand update information displayed to a user.
 34. The business processmanagement system of claim 32 wherein: The inference engine uses thedetermined intent to create at least one plan instance corresponding tothe determined intent.
 35. A computer program product for businessprocess management comprising: a computer readable medium; at least oneknowledge base module, stored on the medium and operative to store andretrieve knowledge related to at least one business process domain,wherein the knowledge comprises at least one possible plan in thebusiness process domain; a user interface module, stored on the mediumand operative to receive at least one goal within the business processdomain at least one inference engine, stored on the medium, eachinference engine: in communication with the knowledge base and the userinterface, and comprising: a partial order planner, the partial orderplanner operative to at least one plan instance from among the possibleplans to achieve a goal.
 36. The computer program product of claim 35wherein the partial order planner is a least commitment partial orderplanner.
 37. The computer program product of claim 36 wherein the leastcommitment partial order planner manages the level of commitment to atleast one instantiated plan by using a state transition method to set alife cycle state of at least one plan element.
 38. The computer programproduct of claim 35 wherein: the inference engine further comprises atleast one situation assessor operative to: activate at least one monitorin response to a request from the partial order planner, and generate anevent signal for each monitor upon satisfaction of a condition; and thepartial order planner is further operative to: request activation of amonitor associated with at least one element of a plan instance upon theestablishment and updating of the life cycle state of at least oneelement of the plan instance; and perform a state transition of thecorresponding plan instance upon receipt of an event signal.
 39. Thecomputer program product of claim 38 wherein: the knowledge furthercomprises scripts and plan-goal graphs; and the inference engine furthercomprises at least one intent interpreter operative to determine anintent of the user, wherein determining the intent of a user comprisesattempting one of: explaining event signals using scripts, andexplaining event signals using plan-goal graphs.
 40. The businessprocess management system of claim 39 wherein: the inference engine usesdetermined intent to choose and update information displayed to a user.41. The business process management system of claim 39 wherein: Theinference engine uses the determined intent to create at least one planinstance corresponding to the determined intent.
 42. A system ofbusiness process management systems comprising a plurality of businessprocess management systems, each business process management system:each business process management system in communication with each otherbusiness process management system; each business process managementsystem comprising: at least one knowledge base operative to store andretrieve knowledge related to at least one business process domain,wherein the knowledge comprises at least one possible plan in thebusiness process domain; a user interface operative to receive at leastone goal within the business process domain at least one inferenceengine, each inference engine: in communication with the knowledge baseand the user interface, and comprising: a partial order planner, thepartial order planner operative to at least one plan instance from amongthe possible plans to achieve a goal; and each business processmanagement system operative to communicate knowledge comprising at leastone of plan instances with the other business process management systemsof the plurality, and notify users of conflicting plan instances. 43.The system of claim 42 wherein each partial order planner is a leastcommitment partial order planner.
 44. The system of claim 43 whereineach least commitment partial order planner manages the level ofcommitment to the plan instance by using a state transition method toset a life cycle state of at least one element of the plan instance. 45.The system of claim 42 wherein: each inference engine further comprisesat least one situation assessor operative to: activate at least onemonitor in response to a request from the partial order planner, andgenerate an event signal for each monitor upon satisfaction of acondition; and each partial order planner is further operative to:request activation of a monitor associated with at least one element ofa plan instance upon the establishment and updating of the life cyclestate of at least one element of the plan instance; and perform a statetransition of the corresponding plan instance upon receipt of an eventsignal.
 46. The system of claim 45 wherein: the knowledge furthercomprises scripts and plan-goal graphs; and each inference enginefurther comprises at least one intent interpreter operative to determinean intent of the user, wherein determining the intent of a usercomprises attempting one of: explaining event signals using scripts, andexplaining event signals using plan-goal graphs.
 47. The system of claim46 wherein: each inference engine uses determined intent to choose andupdate information displayed to a user.
 48. The system of claim 46wherein: each inference engine uses the determined intent to create atleast one plan instance corresponding to the determined intent.